Skip to content

Add new Release Manager PGP key to KEYS#7919

Closed
JinwooHwang wants to merge 1 commit into
apache:developfrom
JinwooHwang:release-manager-keys
Closed

Add new Release Manager PGP key to KEYS#7919
JinwooHwang wants to merge 1 commit into
apache:developfrom
JinwooHwang:release-manager-keys

Conversation

@JinwooHwang

@JinwooHwang JinwooHwang commented Aug 28, 2025

Copy link
Copy Markdown
Contributor

Summary

  • This PR appends the Release Manager’s PGP public key to the KEYS file so that upcoming source release artifacts can be verified by end users and downstream packagers.

Added Key

  • uid: Jinwoo Hwang jinwoo@apache.org
  • Fingerprint: 5C3D A8FB B105 2F4D F1DE B1EF 62F7 DA41 B7D8 F26C
  • Created: 2025-08-28
  • Expires: 2029-08-28

Rationale

  • Enables signature verification (.asc) for the next release cycle.
  • Keeps the project compliant with ASF release policy (all signing keys must be published in KEYS).
  • Ensures build consumers can establish a trust path before validating release artifacts.

Verification Steps (Reviewer)

  1. Pull branch and inspect only appended block at end of KEYS.
  2. Confirm no prior key material modified (e.g. git diff -w KEYS).
  3. Extract and verify fingerprint locally:
    gpg --import KEYS
    gpg --fingerprint 5C3DA8FBB1052F4DF1DEB1EF62F7DA41B7D8F26C
  4. (Optional) Check key on public keyservers / WKD if published:
    gpg --keyserver keys.openpgp.org --recv-keys 62F7DA41B7D8F26C
  5. Dry‑run tag verification example (after a release tag exists):
    gpg --verify apache---src.tar.gz.asc

Release Manager Action After Merge

  • Ensure the key is also uploaded to at least one public keyserver (if not already).
  • Use this key exclusively (or document any key rotation) for signing the release artifacts and staged Maven artifacts (if applicable).
  • Announce fingerprint in the VOTE and RESULT e‑mails.

Integrity Considerations

  • No removal or alteration of existing keys.
  • Single, properly delimited ASCII armored block (-----BEGIN PGP PUBLIC KEY BLOCK----- … -----END PGP PUBLIC KEY BLOCK-----).
  • Fingerprint line in summary matches gpg output.

Request

  • Approve & merge before starting the release vote so voters can pre‑import the key.

For all changes:

  • Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

  • Has your PR been rebased against the latest commit within the target branch (typically develop)?

  • Is your initial contribution a single, squashed commit?

  • Does gradlew build run cleanly?

  • Have you written or updated unit tests to verify your changes?

  • If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

@JinwooHwang JinwooHwang requested a review from raboof August 28, 2025 18:26
CalvinKirs
CalvinKirs reviewed Sep 2, 2025
View reviewed changes

@CalvinKirs CalvinKirs left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ve already uploaded your key to https://downloads.apache.org/geode/KEYS (it may take a little time to sync). This is the way we usually handle it. I also noticed the release documentation follows the same process.

So I’m not sure if we really need to maintain a redundant copy here.

@JinwooHwang

JinwooHwang commented Sep 2, 2025 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Thank you so much for taking care of uploading my key and for explaining the process, @CalvinKirs. I really appreciate your help and the clarification. My apologies for the confusion on my side — it makes perfect sense that we don’t need to maintain a redundant copy. I’ll be sure to follow this process going forward.

@JinwooHwang JinwooHwang closed this Sep 2, 2025
@raboof

raboof commented Sep 22, 2025

Copy link
Copy Markdown
Member

I’ve already uploaded your key to https://downloads.apache.org/geode/KEYS (it may take a little time to sync). This is the way we usually handle it. I also noticed the release documentation follows the same process.

https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode does also have "Add the release manager's public key block to the KEYS file in develop branch"

So I’m not sure if we really need to maintain a redundant copy here.

I kinda like having the git history of the KEYS file in 'regular' version control, so there's a trail explaining when/by who/why a key was added to the store - but I'm not aware of any ASF policy that says it must be here. If we're not updating it, perhaps we should remove it entirely?

@JinwooHwang

JinwooHwang commented Sep 22, 2025

Copy link
Copy Markdown
Contributor Author

@raboof . That makes sense — having the KEYS file in version control does provide a helpful audit trail, especially when tracking who added what and why. Even if it's not mandated by ASF policy, that traceability can be valuable. If we’re no longer maintaining it, though, removing it might help reduce confusion or the illusion of active use. Maybe we could document the rationale somewhere if we do remove it, just to preserve context? Any thoughts, @CalvinKirs ?

@raboof raboof mentioned this pull request Sep 25, 2025
Merged
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@CalvinKirs CalvinKirs CalvinKirs left review comments
@raboof raboof Awaiting requested review from raboof

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@JinwooHwang @raboof @CalvinKirs